在這次 30 天挑戰的第一階段－資料庫設計篇，我們從資料本身出發，關注資料收集管道、儲存架構設計、資料擺放層次及取用的成本等。實踐這些資料庫設計的準則就是資料工程師的核心業務。

曾經聽過一句話：『關注 Data 的 Engineer，才是好的 Data Engineer。』這句話真是把資料工程師的工作日常描繪得淋漓盡致。作為一個資料工程師，我們不僅需要寫出有效率的 SQL，還必須思考如何以最少的成本來收集、儲存和擺放資料。

目前為止，我們從不同的面向切入，理解資料庫的設計原則和實務操作。我們探討了幾個關鍵主題：從正規化與反正規化的取捨，到 OLTP 與 OLAP 的差異，再到資料倉儲的三層架構與不同資料模型結構的選擇。

Key Takeaways | 資料庫設計錦囊

在 Day 02，我們探討了資料庫正規化與反正規化的平衡。正規化可以幫助我們減少資料冗餘，提高資料的一致性，但同時也可能增加查詢的複雜度。反正規化運用另外儲存空間換取查詢效率。藉此解決資料運用瓶頸。

Day 03 的 OLTP 和 OLAP 間的用途區別讓我們看到，業務處理與分析處理系統在架構設計上的核心差異，包含關聯模式及 row/column based 資料庫選用等。理解這些差異，能幫助後端工程師更有效地與資料工程師協作，並確保資料儲存與取用的設計更符合需求。

在 Day 04，我們討論了資料管線的設計與實作。它負責從資料的收集、清理與轉換，到最終載入的完整流程。我們探討了如何構建高效且可擴展的 data pipeline，並討論了 ETL 與 ELT 兩種不同模式的應用場景。

在 Day 05 和 Day 06 中，我們進入了由資料工程師打造的資料儲存體系包含資料湖、資料倉儲、資料湖倉等概念，以及三層式架構的實際應用。每一層的設計都有其目的，同時確保了可擴展性與可維護性。

到了 Day 07，我們俯瞰整個資料倉儲，從結構上可以分成星狀模型與雪花模型兩種。星狀模型查詢效率高、易理解；而雪花模型則減少重複資料儲存，但增加查詢複雜性。

最後在 Day 08，從資料倉儲對於維度資料隨時間變化的保存過程切入，討論了增量載入、全量載入、SCD 等載入方式。從 JOIN 查詢的問題，點出了時間維度在資料倉儲的雙面刃特性，保留得越完整，能夠觀察的異動歷程就越細緻，但也要付出對應的開發成本，以及過度設計造成的查詢困難風險。

Q & A | 也許還是不明白的那些事

最後用兩個自問自答來總結吧！

Q1：後端工程師為什麼覺得『資料工程師就只是寫 SQL』呢？

A：
前幾天文章中提到的少數 Script 確實都是 SQL。不過，那是因為第一階段我們火力集中在說明「資料庫設計原理與考量」，同時強調「關注資料本身」的重要性。若要因此覺得 SQL 是資料工程的全部，那可就見樹不見林了。為了打造完整的資料工程體系，後續我們會慢慢帶出 "軟體工程篇" 及 "基礎建設篇"。
當資料要從業務情境流向分析運用時，身處上游的後端工程師必須理解，在 Application 上對資料庫做出異動，不論是資料表結構的修改 (schema change)，或是資料異動的時間戳記更新，都會是資料工程師與你協作時留意的細節，務必要妥善溝通。

Q2：資料取用者為什麼覺得『資料工程師就是軟體工程師』？

A：
資料分析師與機器學習工程師或許覺得資料工程師與軟體工程師的工作類似，都是在編寫程式碼 (programming) 實現某些功能。
軟體工程師考慮的是程式碼，包含程式碼架構設計與程式碼品質等；但資料工程師思考的中心是資料，包含資料變化、資料處理過程、儲存架構及資料品質；因此，軟體工程師產生高可用的程式碼，資料工程師產生高可用的資料，更為貼近資料取用者的需求。
身為資料取用者，理解資料工程師的設計原理將有助於提報需求時更為具體和精準。舉例而言，提需時能夠一併說明所需資料更新頻率、歷史回溯的必要性，以及後續取用資料應具備的細節層次。這能幫助資料工程師設計合適的資料架構，當然就能滿足你的運用需求囉。

Catalogue | 給你的快速連結

[09/22]《資料與程式碼的交鋒》Day 08 - 資料保鮮度
[09/21]《資料與程式碼的交鋒》Day 07 - 星狀模型 v.s. 雪花模型
[09/20]《資料與程式碼的交鋒》Day 06 - 資料倉儲的三層式架構
[09/19]《資料與程式碼的交鋒》Day 05 - 資料倉儲/湖/湖倉
[09/18]《資料與程式碼的交鋒》Day 04 - 資料管線 Data Pipeline
[09/17]《資料與程式碼的交鋒》Day 03－OLTP v.s. OLAP 的差異
[09/16]《資料與程式碼的交鋒》Day 02 - 資料庫正規化與反正規化
[09/15]《資料與程式碼的交鋒》Day 01 - 前言